Skip to content
This repository has been archived by the owner on Apr 17, 2019. It is now read-only.

refactored iroha::expected::Result #2226

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

MBoldyrev
Copy link
Contributor

Signed-off-by: Mikhail Boldyrev [email protected]

Description of the Change

Finally I got too tired of typing the arguments of iroha::expected::Result::match functions. Looking at its signature and docstring comment, I saw that the first matcher is for the value case, and the second - for the error. But this deduction did not happen, because both were just passed to some sort of apply_visitor, which does not care of visitors' positions. So I made a change before the visitor application, forcing the first visitor to accept value type, and the second - error type.

Benefits

saves some hair on your head. just see this:

-        auto block = getBlock(i);
-        block.match(
-            [&result](
-                expected::Value<std::unique_ptr<shared_model::interface::Block>>
-                    &v) { result.emplace_back(std::move(v.value)); },
-            [this](const expected::Error<std::string> &e) {
-              log_->error(e.error);
-            });
+        getBlock(i).match(
+            [&result](auto &&v) { result.emplace_back(std::move(v.value)); },
+            [this](const auto &e) { log_->error(e.error); });

Possible Drawbacks

Usage Examples or Tests [optional]

just use auto type in matchers. don't forget about matched Result const- and ref-qualifiers: for example, if it is an rvalue (most common case), use either auto && or const auto & argument type in your machers.

Alternate Designs [optional]

Signed-off-by: Mikhail Boldyrev <[email protected]>
@MBoldyrev MBoldyrev added needs-review pr awaits review from maintainers refactoring internal stuff, that are changed/removed that doesn't affect client code labels Apr 13, 2019
@MBoldyrev MBoldyrev self-assigned this Apr 13, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
needs-review pr awaits review from maintainers refactoring internal stuff, that are changed/removed that doesn't affect client code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant